A Philosophy Of Software Design
https://m.media-amazon.com/images/I/51o+gQtCIiL._SX342_SY445_.jpg
https://qiita.com/immrshc/items/73f9a9c5d7453273e371
https://speakerdeck.com/iwashi86/understand-roughly-philosophy-of-software-design-in-30-minutes
優れたプログラマと平凡なプログラマを分けるのは、設計スキルである。
設計の目標は、ソフトウェアの複雑さを軽減することである。
本書の目標
「複雑さ」の本質について
「複雑さ」とはなにか
なぜ「複雑さ」が重要なのか
不必要な「複雑さ」をどのように見分けるか
「複雑さ」を最小限に抑えるテクニック
使い方
抽象的かつ説明用のコードが少ないので、コードレビュー(他人のコードを読むとき)と併用するのがおすすめ
他人のコードのほうが設計上の問題を見つけやすい
本書で議論されている内容に適合しているか、どう改善できるかを見る
それがコードの「複雑さ」とどう関係しているか
ただし、どんなルールにも例外はある
極限まで追求すると、結果として悪い方向に進んでしまう
各章の Taking it too far セクションでは、やりすぎていることを見極めるための方法を示している
設計スキルを向上させるには、レッドフラグを見分ける方法を学ぶこと
本書では主要な設計上の問題に関連するレッドフラグを紹介する
レッドフラグを取り除くため設計案を見つけるまでに、様々な設計案を試す必要もある
試せば試すほど、より多くのものが得られる
セクション
✅ 1. It's All Abount Complexity
✅ 2. The Nature Of Complexity
✅ 3. Working Code Isn't Enough
✅ 4. Modules Should Be Deep
✅ 5. Information Hiding (and Leakage)
✅ 6. General-Purpose Modules and Deeper
✅ 7. Differenct Layer, Different Abstruction
✅ 8. Pull Complexity Downwards
9. Better Together Or Better Apart?
10. Define Errors Out Of Extence
✅ 11. Design Twice
✅ 12. Why Write Comments? The Four Exercises
13. Comments Should Describe Things that Ain't Obvious from the Code
✅ 14. Choosing Names
✅ 15. Write The Comments First
✅ 16. Modifying Existing Code
✅ 17. Consistency
✅ 18. Code Should Be Obvious
19. Software Trends
20. Designing for Performance
21. Decide What Matters
英語 -> radish-miyazaki.icon -> 日本語なので、原文と乖離しているところも…
#設計 #読書メモ #読書中